System, Method and Devices for MKA Negotiation Between the Devices

ABSTRACT

Disclosed are a system, method and devices for simultaneous MACsec key agreement (MKA) negotiation between the devices. The present application controls a basic TLV message exchange between supplicant and authenticator in case of race condition to establish the secure association key (SAK) channel. The present application by controlling a basic TLV message exchange enables to establish a secure channel in race condition and achieves a high reliability of the product as this makes product launch MACsec services quickly and available for the service. Accordingly, when both sides (two supplicants) exchange hello with basic TLV at the same time, triggering the race condition, drops first message from the authenticator at supplicant and update the peer MN and the supplicant will not send reply. The authenticator when send next message (basic+potential peer TLV) with peer MN incremented by  1 , the supplicant will respond with incremental message with live peer TLV.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/420,959, filed on May 23, 2019, which is a continuation ofInternational Application No. PCT/CN2017/111141, filed on Nov. 15, 2017,which claims priority to India Patent Application No. 201641040427 filedon Nov. 26, 2016. All of the aforementioned patent applications arehereby incorporated by reference in their entireties.

TECHNICAL FIELD

The present subject matter described herein, in general, relates tocommunication networks and more particularly to port-based networkaccess control.

BACKGROUND

IEEE 802.1AE is the IEEE MAC Security standard (also known as MACsec)and defines connectionless data confidentiality and integrity for mediaaccess independent protocols. MACsec is defined for authenticating andencrypting packets between two MACsec-capable devices. However, keymanagement and the establishment of secure associations are specified byIEEE 802.1X-2010. IEEE 802.1X is an IEEE Standard for Port-based NetworkAccess Control (PNAC) and is part of the IEEE 802.1 group of networkingprotocols. IEEE 802.1X provides an authentication mechanism to deviceswishing to attach to a local area network (LAN) or wireless local areanetwork (WLAN). Specifically, MACsec provides a secure communication ona wired LAN. IEEE 802.1X defines two logical port entities for anauthenticated port: a “controlled port” and an “uncontrolled port”. Thecontrolled port is manipulated by the 802.1X PAE (Port Access Entity) toallow (in the authorized state) or prevent (in the unauthorized state)network traffic ingressing and egressing to/from the controlled port.The uncontrolled port is used by the 802.1X PAE to transmit and receiveExtensible Authentication Protocol over LAN (EAPOL) frames.

Generally, 802.1X authentication involve three parties: a supplicant, anauthenticator, and an authentication server. The supplicant is a clientdevice (such as a laptop) that wishes to attach to the LAN/WLAN. Theterm ‘supplicant’ is also used interchangeably to refer to the softwarerunning on the client that provides credentials to the authenticator. Tosupport MACsec, the supplicant should be able to manage MACsec keynegotiation and encrypt packets. The authenticator is a network accessdevice that facilitates the authentication process by replaying thesupplicant's credentials to the authentication server. The authenticatormay be an Ethernet switch or a wireless access point. The authenticationvalidates the supplicant's credentials and determines what networkaccess the supplicant should receive. The authentication server may be aRADIUS server. In MACsec, the authentication server plays an importantrole in the distribution of master keying material to the supplicant andauthenticator. In addition, the authentication server can define theMACsec policy to be applied to a particular endpoint. A MACsec agreementincludes three phases: an authentication phase, a key negotiation and amessage encryption transmission phase as shown in FIG. 1.

As shown in FIG. 1, in the authentication phase a supplicant port accessentity (PAE) and an authenticator PAE will commonly use an extensibleauthentication protocol transport layer security (EAP-TLS) method for802.1x authentication process, with a two-way certificate exchange. Theports on both PAEs are declared secure after successful exchange andvalidation of peer PAE's certificate. The process is repeatedperiodically to re-authenticate the PAE to enhance security. The defaultperiod of the authentication phase is 3600 s.

In the key agreement phase, while authentication process, the PAEs firstnegotiate a master session key (MSK). According to MACsec Key Agreementprotocol (MKA), the MSK is used to generate CAK (ConnectivityAssociation Key). One PAE is chosen as a key server and this PAE actingas the key server generates a key, encrypts and sends the key to otherPAEs. The key server periodically updates the key to prevent cracking.The default cycle of the key agreement phase is 1800 s.

In encrypted transmission phase, 802.1AE-2006 defines the process ofencrypting the messages sent from the secured port. The key used forencryption is generated distributed to all other PAEs during keyagreement.

Referring now to FIG. 2, MKA process between 2 PAEs (one designated asauthenticator and the other as supplicant) is as shown. The PAE A(supplicant) initiates MKA process by sending a MACsec key agreementprotocol data unit (MKPDU) with just basic Type-Length-Value (TLV)information. This TLV contains a field called Message Number (MN), whichhas to be unique for every MKPDU, and has to be incremented for eachpacket that is sending out. On receiving an MKPDU, if a basicauthentication is successful, then the receiver PAE B (authenticator)stores the received MN and reflects this by sending back a response withPAE B's MKPDU, wherein PAE B's MKPDU includes a potential peer TLV. WhenPAE A receives this response from PAE B, PAE A checks the potential peerTLV in the response. The potential peer TLV should contain a MessageIndicator (MI) and an MN used in the last MKPDU that was sent to PAE B.If the MN in the potential peer TLV is older, PAE A rejects this TLV. Ifthe potential peer TLV is acceptable, PAE A adds PAE B to a list of livepeer. MKA key is distributed once both PAE A and PAE B add each other totheir live peer list.

Referring now to FIG. 3, a conventional MKA process is shown. In the MKAprocess of FIG. 3, it is expected that only one of the PAE initiates MKAprocess at a time. However, as per standard, there is no mechanism tocontrol when a PAE initiates MKA process. So, if multiple PAEs comealive simultaneously (for example, say 2 devices startup at the sametime), they may all initiate MKA process simultaneously. This can leadto the MKA failure, and a secure data channel cannot be established.MACsec protocol does not define a mechanism to prevent the abovescenario.

Referring now to FIG. 4, a scenario of simultaneous initiation of MKAnegotiations between PAE A and PAE B and the associated limitation ortechnical problem to the same. As shown in FIG. 4, PAE A and PAE Binitiate MKA by sending an MKPDU with basic parameter TLV containing theassociated message indicator (MI) and MN. When PAE A receives the MKPDUsent by PAE B, PAE A add PAE B to PAE A's live peer list only if thereceived MKPDU contains the most recent MI and MN sent by PAE A. SinceMKA was initiated simultaneously, the MKPDUs from PAE A and PAE B aresent at the same time, so the last MI and MN sent from PAE A will neverbe reflected back by PAE B. Therefore, the peer liveness cannot beestablished, and MKA keys are not distributed and a secure data channelcannot be build.

The above-described deficiencies of existing MKA negotiation between PAEentities are merely intended to provide an overview of some of theproblems of conventional systems/mechanism/techniques, and are notintended to be exhaustive. Other problems with conventionalsystems/mechanism/techniques and corresponding benefits of the variousnon-limiting embodiments described herein may become further apparentupon review of the following description.

SUMMARY

This summary is provided to introduce concepts related to system, methodand devices for simultaneous MACsec key agreement (MKA) negotiationbetween the devices, and the same are further described below in thedetailed description. This summary is not intended to identify essentialfeatures of the claimed subject matter nor is it intended for use indetermining or limiting the scope of the claimed subject matter.

An objective of the present application is to solve the technicalproblem as recited above by controlling the basic Type-Length-Value(TLV) message exchange between the PAE's (supplicant and authenticator)in case of race condition to establish a secure association key (SAK)channel.

Another objective of the present application is to provide a system,device and a method for simultaneous MKA negotiation between PAEentities (supplicant and authenticator).

Accordingly, the present application provides a system. The system isused for provisioning a simultaneous key negotiation process to achievesecure communication, and has a plurality of port access entities. Thesystem comprises at least one first port access entity, from theplurality of port access entities, adapted to initiate a key agreementprocess by sending a first message with at least a basic TLV informationto at least one second port access entity from the plurality of portaccess entities, the TLV comprises at least a message number (MN) and amessage indicator (MI) unique for the first message sent; receive asecond message with at least a potential peer TLV from the at least onesecond port access entity in response to the first message, thepotential peer TLV comprises at least a message number (MN) and amessage indicator (MI) unique for at least one message receivedeventually by the at least one second port access entity; detect anoccurrence of a simultaneous key agreement process session initiation,indicating a race condition, based at least on the message number (MN)received with the second message; store, if the race condition isdetected, the message number (MN) received with the second message; andrespond by sending a third message to the at least one second portaccess entity with the message number (MN) stored and a live peer TLV toachieve the key agreement process, wherein the third message is sentwhen the message number (MN) associated with the first message isreceived in the potential peer TLV from the at least one second portaccess entity.

In one implementation, the present application provides method forprovisioning a simultaneous key negotiation process to achieve securecommunication. The method includes initiating, by at least one firstport access entity, a key agreement process by sending a first messagewith at least a basic TLV information to at least one second port accessentity, the TLV comprises at least a message number (MN) and a messageindicator (MI) unique for the first message sent; receiving, by the atleast one first port access entity, a second message with at least apotential peer TLV from the at least one second port access entity inresponse to the first message, the potential peer TLV comprises at leasta message number (MN) and a message indicator (MI) unique for at leastone message received eventually by the at least one second port accessentity; detecting an occurrence of a simultaneous key agreement processsession initiation, indicating a race condition, based at least on themessage number (MN) received with the second message; storing, if therace condition is detected, by the at least one first port accessentity, the message number (MN) received with the second message; andresponding, by the at least one first port access entity, by sending athird message with the message number (MN) stored and a live peer TLV toachieve the key agreement process, wherein the third message is sentwhen the message number (MN) associated with the first message isreceived in the potential peer TLV from the at least one second portaccess entity.

In one implementation, the present application provides a device forprovisioning a simultaneous key negotiation process to achieve securecommunication. The device includes a processor and a memory coupled tothe processor for executing a plurality of modules present in thememory. The plurality of modules includes a transmitting module, areceiving module, a detection module, a storage module, and a responsemodule.

The transmitting module is configured to initiate a key agreementprocess by sending a first message with at least basic TLV informationto at least one port access entity, the TLV comprises at least a messagenumber (MN) and a message indicator (MI) unique for the first messagesent.

The receiving module is configured to receive a second message with atleast a potential peer TLV from the at least one port access entity inresponse to the first message, the potential peer TLV comprises at leasta message number (MN) and a message indicator (MI) unique for at leastone message received eventually by the at least one port access entity.

The detection module is configured to detect an occurrence of asimultaneous key agreement process session initiation, indicating a racecondition, based at least on the message number (MN) received with thesecond message.

The storage module is configured to store the message number (MN)received with the second message if the race condition is detected.

The response module is configured to respond by sending a third messageto the at least one second port access entity with the message number(MN) stored and a live peer TLV to achieve the key agreement process,wherein the third message is sent when the message number (MN)associated with the first message is received in the potential peer TLVfrom the at least one second port access entity.

In contrast to the available techniques, the present application enablesto establish the secure channel in race condition scenario and helps inachieving high reliability of the product as this makes product launchMACsec services quickly and available for the service.

The various options and preferred embodiments referred to above inrelation to the first implementation are also applicable in relation tothe other implementations.

BRIEF DESCRIPTION OF THE DRAWINGS

The detailed description is described with reference to the accompanyingfigures. In the figures, the left-most digit(s) of a reference numberidentifies the figure in which the reference number first appears. Thesame numbers are used throughout the drawings to refer like features andcomponents.

FIG. 1 illustrates the authentication phase, a key negotiation andmessage encryption transmission phase associated with the MACsecagreement, according to the prior-art.

FIG. 2 illustrates MKA process between 2 PAEs, according to theprior-art.

FIG. 3 illustrates another MKA process, according to the prior-art.

FIG. 4 illustrates a simultaneous initiation of MKA negotiations betweenPAE A and PAE B, according to the prior-art.

FIG. 5 illustrates a MKA session, in accordance with an embodiment ofthe present subject matter.

FIG. 6 illustrates a system, for provisioning a simultaneous keynegotiation process to achieve secure communication, having a pluralityof port access entities, in accordance with an embodiment of the presentsubject matter.

FIG. 7 illustrates a device for provisioning a simultaneous keynegotiation process to achieve secure communication, in accordance withan embodiment of the present subject matter.

FIG. 8 illustrates a method for provisioning a simultaneous keynegotiation process to achieve secure communication, in accordance withan embodiment of the present subject matter.

It is to be understood that the attached drawings are for purposes ofillustrating the concepts of the application and may not be to scale.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

The application can be implemented in numerous ways, as a process, anapparatus, a system, a composition of matter, a computer readable mediumsuch as a computer readable storage medium or a computer network whereinprogram instructions are sent over optical or electronic communicationlinks. In this specification, these implementations, or any other formthat the application may take, may be referred to as techniques. Ingeneral, the order of the steps of disclosed processes may be alteredwithin the scope of the application.

A detailed description of one or more embodiments of the application isprovided below along with accompanying figures that illustrate theprinciples of the application. The application is described inconnection with such embodiments, but the application is not limited toany embodiment. The scope of the application is limited only by theclaims and the application encompasses numerous alternatives,modifications and equivalents. Numerous specific details are set forthin the following description in order to provide a thoroughunderstanding of the application. These details are provided for thepurpose of example and the application may be practiced according to theclaims without some or all of these specific details. For the purpose ofclarity, technical material that is known in the technical fieldsrelated to the application has not been described in detail so that theapplication is not unnecessarily obscured.

In the following detailed description, numerous specific details are setforth in order to provide a thorough understanding of the application.However, it will be understood by those skilled in the art that thepresent application may be practiced without these specific details. Inother instances, well-known methods, procedures, and components,modules, units and/or circuits have not been described in detail so asnot to obscure the application.

Although embodiments of the application are not limited in this regard,discussions utilizing terms such as, for example, “processing,”“computing,” “calculating,” “determining,” “establishing”, “analyzing”,“checking”, or the like, may refer to operation(s) and/or process(es) ofa computer, a computing platform, a computing system, or otherelectronic computing device, that manipulates and/or transforms datarepresented as physical (e.g., electronic) quantities within thecomputer's registers and/or memories into other data similarlyrepresented as physical quantities within the computer's registersand/or memories or other information non-transitory storage medium thatmay store instructions to perform operations and/or processes.

Although embodiments of the application are not limited in this regard,the terms “plurality” and “a plurality” as used herein may include, forexample, “multiple” or “two or more”. The terms “plurality” or “aplurality” may be used throughout the specification to describe two ormore components, devices, elements, units, parameters, or the like.Unless explicitly stated, the method embodiments described herein arenot constrained to a particular order or sequence. Additionally, some ofthe described method embodiments or elements thereof can occur or beperformed simultaneously, at the same point in time, or concurrently.

System, method and devices for simultaneous MACsec key agreement (MKA)negotiation between the devices are disclosed.

While aspects are described for system, method and devices forsimultaneous MKA negotiation between the devices, the presentapplication may be implemented in any number of different computingsystems, environments, and/or configurations, the embodiments aredescribed in the context of the following exemplary systems,devices/nodes/apparatus, and methods.

Henceforth, embodiments of the present disclosure are explained with thehelp of exemplary diagrams and one or more examples. However, suchexemplary diagrams and examples are provided for the illustrationpurpose for better understanding of the present disclosure and shouldnot be construed as limitation on scope of the present disclosure.

Referring again to FIG. 4, PAE A initiates MKA by sending an MKPDU withbasic parameter Type-Length-Value (TLV) and the basic parameter TLVcontains an associated MI and an associated MN. When PAE A receives theMKPDU sent by PAE B, PAE A adds PAE B to PAE A's live peer list when thereceived MKPDU contains the most recent MI and MN sent by PAE A. SinceMKA was initiated simultaneously, MKPDUs from PAE A and PAE B are sentat the same time, so the last sent MI and MN from PAE A will never bereflected back by PAE B. Therefore, peer liveness cannot be established,and MKA keys are not distributed and a secure data channel cannot bebuild. Such scenario is referred to as a race condition throughout theapplication. The race condition is a condition wherein the MKA isinitiated simultaneously by multiple devices and the MKPDU from PAE Aand PAE B are sent at the same time, so the last send MI and MN from PAEA will never be reflected back by PAE B.

Such race condition can be avoided if the supplicant (sender) can detectthat the potential peer (an authenticator) does not receive the last MIand MN, and the supplicant can drop an MKPDU from the authenticator butthe supplicant updates the MI and MN in potential peer list.

Thus, the present application controls a basic TLV message exchangebetween a supplicant and an authenticator in case of race condition toestablish the secure association key (SAK) channel. The presentapplication controls a basic TLV message exchange and a secure channelcan be established in race condition scenario and improves reliabilityof the product and the product can launch MACsec services quickly andavailable for the service.

Accordingly, when both sides (two supplicants) exchange hello with basicTLV at the same time, triggering the race condition, the supplicant dropfirstly a message from the authenticator (peer) and update the peer MNand the supplicant will not reply. The authenticator sends a nextmessage (basic+potential peer TLV) with a peer MN incremented by 1, thesupplicant will respond with reply message with live peer TLV and thereply message has an MN incremented by 1.

In one implementation, the present application provides a mechanismdetecting the occurrence of simultaneous MKA session initiation, and thesupplicant holding back from the negotiation till the race conditiondisappears.

The supplicant may recognize a race condition when the supplicantreceives an MKA basic parameter TLV from the peer (authenticator) butthe supplicant does not receive a reply after the supplicant has sent aMKA basic parameter TLV to that peer before. In this case, thesupplicant recognize simultaneous session initiation, the supplicantwill store an MN received from the supplicant's peer but does notrespond to the peer till the supplicant is reflected in the peer's MKAmessage under potential or live peer TLV.

Referring now to FIG. 5 illustrates a MKA session to avoid a racecondition by using the mechanism of the present application. As shown inFIG. 5, the supplicant recognizes that the MKPDU with MN B+1 is receivedinstead of MN A+1, due to simultaneous initiation. The supplicantrecords the MN B+1 from the peer. Then the supplicant may drop theMKPDU. The authenticator processes the initial MKPDU sent by thesupplicant and sends a next MKPDU reflecting the supplicant's latest MIand MN. Since only one side drops the MKPDU, the race condition isbroken and the MKA process proceeds normally. The key exchange maysucceed and a secure data channel may be established.

Referring now to FIG. 6, a system for provisioning a simultaneous keynegotiation process to achieve secure communication is disclosed. Thesystem includes a plurality of port access entities. The systemcomprises at least one first port access entity 601-1, 601-2, . . .601-N, collectively referred to as 601 hereinafter, from the pluralityof port access entities. The first port access entity 601 is configuredto initiate a key agreement process by sending a first message with atleast basic TLV information to at least one second port access entity602 from the plurality of port access entities, the TLV informationcomprises at least a message number (MN) and a message indicator (MI)unique for the first message. The first port access entity 601 receive asecond message with at least a potential peer TLV from the at least onesecond port access entity in response to the first message. Thepotential peer TLV comprises at least an MN and an MI unique for atleast one message received eventually by the at least one second portaccess entity 602. The first port access entity 601 detect an occurrenceof a simultaneous key agreement process session initiation, indicating arace condition, based at least on the received MN together with thesecond message. The first port access entity 601 stores, if the racecondition is detected, the MN received together with the second message.The first port access entity 601 then responds by sending a thirdmessage to the at least one second port access entity with the stored MNand a live peer TLV to achieve the key agreement process, wherein athird message is sent when the MN associated with the first message isreceived in the potential peer TLV from the at least one second portaccess entity.

In one implementation, the race condition occurs if multiple first portaccess entities from the plurality of port access entities initiate akey agreement process simultaneously.

In one implementation, the race condition is identified when thepotential peer TLV received from the peer does not contain the MN forthe first message sent by the sender even after having sent the basicTLV information to the peer.

In one implementation, the key agreement process is a MAC security(MACsec) Key Agreement protocol (MKA) key negotiation process.

In one implementation, the first message, the second message and thethird message are MAC security (MACsec) key agreement protocol data unit(MKPDU).

In one implementation, the at least one first port access entityreceives the message number (MN) associated with the first message inthe potential peer TLV from the at least one second port access entityunder potential or live peer TLV.

In one implementation, the at least one first port access entity isfurther configured to hold response, upon occurrence of the racecondition, to the at least one second port access entity till the racecondition is avoided.

In one implementation, the race condition is avoided when the supplicantis reflected in the peers MKA message under potential or live peer TLV.

In one implementation, the system is technical advanced over theprior-art as it provides a simultaneous MACsec Key Agreement (MKA)negotiation between the port access entities to achieve securecommunication on wired network.

In one implementation, the at least one second port access entity isconfigured to process the first message received.

Although the present subject matter is explained considering that the atleast one first port access entity 601 is implemented as a first portaccess entity, it may be understood that the at least one first portaccess entity 601 may also be implemented in a variety of computingsystems, such as a laptop computer, a desktop computer, a notebook, aworkstation, a mainframe computer, a server, a network server, and thelike. It will be understood that the at least one first port accessentity 601 may be accessed by multiple users through one or more userdevices, or applications residing on the user devices. Examples of theat least one first port access entity 601 may include, but are notlimited to, a portable computer, a personal digital assistant, ahandheld device, and a workstation. The at least one first port accessentity 601 are communicatively coupled to the at least one second portaccess entity 602 through a network (not shown).

In one implementation, the network may be a wireless network, a wirednetwork or a combination thereof. The network can be implemented as oneof the different types of networks, such as intranet, local area network(LAN), wide area network (WAN), the internet, and the like. The networkmay either be a dedicated network or a shared network. The sharednetwork represents an association of the different types of networksthat use a variety of protocols, for example, Hypertext TransferProtocol (HTTP), Transmission Control Protocol/Internet Protocol(TCP/IP), Wireless Application Protocol (WAP), and the like, tocommunicate with one another. Further the network may include a varietyof network devices, including routers, bridges, servers, computingdevices, storage devices, and the like.

Referring now to FIG. 7, a device 700 for provisioning a simultaneouskey negotiation process to achieve secure communication is illustratedin accordance with an embodiment of the present subject matter.

In one embodiment, the device 700 comprises a memory 706 and a processor702 communicating with the memory 706. Optionally, the device 700comprises an I/O interface 704 and an interconnection mechanism couplingthe memory 706, the processor 702 and the communications interface 704.The processor 702 may be implemented as one or more microprocessors,microcomputers, microcontrollers, digital signal processors, centralprocessing units, state machines, logic circuitries, and/or any devicesthat manipulate signals based on operational instructions. Among othercapabilities, the at least one processor 702 is configured to fetch andexecute computer-readable instructions stored in the memory 706.

The I/O interface 704 may include a variety of software and hardwareinterfaces, for example, a web interface, a graphical user interface,and the like. The I/O interface 704 may allow device 700 to interactwith a user directly or through the user devices 704. Further, the I/Ointerface 704 may enable the device 700 to communicate with othercomputing devices, such as web servers and external data servers (notshown). The I/O/user interface 704 can facilitate multiplecommunications within a wide variety of networks and protocol types,including wired networks, for example, LAN, cable, etc., and wirelessnetworks, such as WLAN, cellular, or satellite. The I/O interface 704may include one or more ports for connecting a number of devices to oneanother or to another server.

The memory 706 may include any computer-readable medium known in the artincluding, for example, volatile memory, such as static random accessmemory (SRAM) and dynamic random access memory (DRAM), and/ornon-volatile memory, such as read only memory (ROM), erasableprogrammable ROM, flash memories, hard disks, optical disks, andmagnetic tapes. The memory 706 may include modules and data (not shown).

The modules include routines, programs, objects, components, datastructures, etc., which perform particular tasks or implement particularabstract data types. In one embodiment, the plurality of modulesincludes a transmitting module 708, a receiving module 710, a detectionmodule 712, a storage module 714, and a response module 716.

The transmitting module 708 is configured to initiate a key agreementprocess by sending a first message with at least basic TLV informationto at least one port access entity, the TLV comprises at least a messagenumber (MN) and a message indicator (MI) unique for the first messagesent.

The receiving module 710 is configured to receive a second message withat least a potential peer TLV from the at least one port access entityin response to the first message, the potential peer TLV comprises atleast a message number (MN) and a message indicator (MI) unique for atleast one message received eventually by the at least one port accessentity.

The detection module 712 is configured to detect an occurrence of asimultaneous key agreement process session initiation, indicating a racecondition, based at least on the message number (MN) received with thesecond message.

The storage module 714 is configured to store the message number (MN)received with the second message if the race condition is detected.

The response module 716 is configured to respond by sending a thirdmessage to the at least one second port access entity with the messagenumber (MN) stored and a live peer TLV to achieve the key agreementprocess, wherein the third message is sent when the message number (MN)associated with the first message is received in the potential peer TLVfrom the at least one second port access entity.

In one implementation, the race condition occurs if multiple devicesinitiate a key agreement process simultaneously.

In one implementation, the race condition is identified when thepotential peer TLV received from the peer does not contain the messagenumber (MN) for the first message sent by the sender even after havingsent the basic TLV information to the peer.

In one implementation, the key agreement process is a Mac security(MACsec) Key Agreement protocol (MKA) key negotiation process.

In one implementation, the first message, the second message and thethird message are Mac security (MACsec) key agreement protocol data unit(MKPDU).

In one implementation, the at least one first port access entityreceives the message number (MN) associated with the first message inthe potential peer TLV from the at least one second port access entityunder potential or live peer TLV.

In one implementation, the device is further configured to holdresponse, upon occurrence of the race condition, to the at least onesecond port access entity till the race condition is avoided.

In one implementation, the race condition is avoided when the supplicantis reflected in the peers MKA message under potential or live peer TLV.

In one implementation, the at least one second port access entity isadapted to process the first message received.

Referring now to FIG. 8, a method for provisioning a simultaneous keynegotiation process to achieve secure communication is illustrated, inaccordance with an embodiment of the present subject matter. The methodmay be described in the general context of computer executableinstructions. Generally, computer executable instructions can includeroutines, programs, objects, components, data structures, procedures,modules, functions, etc., that perform particular functions or implementparticular abstract data types. The method may also be practiced in adistributed computing environment where functions are performed byremote processing devices that are linked through a communicationsnetwork. In a distributed computing environment, computer executableinstructions may be located in both local and remote computer storagemedia, including memory storage devices.

The order in which the method is described is not intended to beconstrued as a limitation, and any number of the described method blockscan be combined in any order to implement the method or alternatemethods. Additionally, individual blocks may be deleted from the methodwithout departing from the protection scope of the subject matterdescribed herein. Furthermore, the method can be implemented in anysuitable hardware, software, firmware, or combination thereof. However,for ease of explanation, in the embodiments described below, the methodmay be considered to be implemented in the above described device 700and/or the at least one second port access entity 601.

At block 802, at least one first port access entity initiates a keyagreement process by sending a first message with at least basic TLVinformation to at least one second port access entity, the TLV comprisesat least a message number (MN) and a message indicator (MI) unique forthe first message.

In one embodiment, the key agreement process is a MAC security (MACsec)Key Agreement protocol (MKA) key negotiation process.

At block 804, the at least one first port access entity 601 receives asecond message with at least a potential peer TLV from the at least onesecond port access entity 602 in response to the first message, thepotential peer TLV comprises at least a message number (MN) and amessage indicator (MI) unique for at least one message receivedeventually by the at least one second port access entity 602.

In one embodiment, the first port access entity 601 receives the messagenumber (MN) associated with the first message in the potential peer TLVfrom the at least one second port access entity under potential or livepeer TLV.

At block 806, the at least one first port access entity 601 detects anoccurrence of a simultaneous key agreement process session initiation,indicating a race condition, based at least on the message number (MN)received with the second message.

In one embodiment, upon detection of the race condition, the at leastone second port access entity 601 holds sending response to the at leastone second port access entity 602 till the race condition is avoided.

At block 808, if the race condition is detected, the at least one firstport access entity 601 stores the message number (MN) received with thesecond message. The race condition is identified when the potential peerTLV received from the peer does not contain the message number (MN) forthe first message sent by the sender even after having sent the basicTLV information to the peer.

In one embodiment, the race condition occurs if multiple first portaccess entities from the plurality of port access entities initiate akey agreement process simultaneously.

At block 808, when the message number (MN) associated with the firstmessage is received by the at least one first port access entity 601 inthe potential peer TLV from the at least one second port access entity,the at least one first port access entity 601 responds to the at leastone second port access entity 602 by sending a third message with themessage number (MN) stored and a live peer TLV to achieve the keyagreement process.

In one embodiment, the first entity 601 responds to the second entityupon avoiding the race condition detected. The race condition is avoidedwhen the supplicant is reflected in the peers MKA message underpotential or live peer TLV.

The method is technical advance over the prior-art literature as themethod provides a simultaneous MACsec Key Agreement (MKA) negotiationbetween the port access entities to achieve secure communication onwired network.

In one embodiment, the first message, the second message and the thirdmessage are MAC security (MACsec) key agreement protocol data unit(MKPDU).

Apart from what is discussed above, some of the other advantages andfeature of the present subject matter are as provided below:

-   -   i. The present application enables the suppliant to drop the        Peer's ‘hello’ message at supplicant upon detection of a race        condition.    -   ii. The present application enables the suppliant to record a        message number of the peer.    -   iii. The present application enables the suppliant to send a        response from the authenticator with an incremental number.    -   iv. The present application enables to establish the secure        channel in race condition scenario.    -   v. The present application achieves high reliability of the        product as this makes product launch MACsec services quickly and        available for the service.

A person skilled in the art may understand that any known or newalgorithms by be used for the implementation of the present application.However, it is to be noted that, the present application provides amethod to be used during back up operation to achieve the abovementioned benefits and technical advancement irrespective of using anyknown or new algorithms.

A person of ordinary skill in the art may be aware that in combinationwith the examples described in the embodiments disclosed in thisspecification, units and algorithm steps may be implemented byelectronic hardware, or a combination of computer software andelectronic hardware. Whether the functions are performed by hardware orsoftware depends on the particular applications and design constraintconditions of the technical solution. A person skilled in the art mayuse different methods to implement the described functions for eachparticular application, but it should not be considered that theimplementation goes beyond the scope of the present application.

In the several embodiments provided in the present application, itshould be understood that the disclosed system, apparatus, and methodmay be implemented in other manners. For example, the describedapparatus embodiment is merely exemplary. For example, the unit divisionis merely logical function division and may be other division in actualimplementation. For example, a plurality of units or components may becombined or integrated into another system, or some features may beignored or not performed. In addition, the displayed or discussed mutualcouplings or direct couplings or communication connections may beimplemented through some interfaces. The indirect couplings orcommunication connections between the apparatuses or units may beimplemented in electronic, mechanical, or other forms.

When the functions are implemented in a form of a software functionalunit and sold or used as an independent product, the functions may bestored in a computer-readable storage medium. Based on such anunderstanding, the technical solutions of the present applicationessentially, or the part contributing to the prior art, or a part of thetechnical solutions may be implemented in a form of a software product.The computer software product is stored in a storage medium, andincludes several instructions for instructing a computer node (which maybe a personal computer, a server, or a network node) to perform all or apart of the steps of the methods described in the embodiment of thepresent application. The foregoing storage medium includes: any mediumthat can store program code, such as a USB flash drive, a removable harddisk, a read-only memory (Read-Only Memory, ROM), a random access memory(Random Access Memory, RAM), a magnetic disk, or an optical disc.

Devices that are in communication with each other need not be incontinuous communication with each other, unless expressly specifiedotherwise. In addition, devices that are in communication with eachother may communicate directly or indirectly through one or moreintermediaries.

When a single device or article is described herein, it will be readilyapparent that more than one device/article (whether or not theycooperate) may be used in place of a single device/article. Similarly,where more than one device or article is described herein (whether ornot they cooperate), it will be readily apparent that a singledevice/article may be used in place of the more than one device orarticle or a different number of devices/articles may be used instead ofthe shown number of devices or programs. The functionality and/or thefeatures of a device may be alternatively embodied by one or more otherdevices which are not explicitly described as having suchfunctionality/features. Thus, other embodiments of the application neednot include the device itself.

Although implementations for system, method and devices for simultaneousMACsec key agreement (MKA) negotiation between the devices have beendescribed in language specific to structural features and/or methods, itis to be understood that the appended claims are not necessarily limitedto the specific features or methods described. Rather, the specificfeatures and methods are disclosed as examples of implementations of thesystem, method and devices for simultaneous MACsec key agreement (MKA)negotiation between the devices.

What is claimed is:
 1. A key agreement system comprising: a first port access entity (PAE) and a second PAE, configured to: exchange, by the first PAE and the second PAE, a first message and a second message with each other to initiate a key agreement process, wherein the first message comprises a first message number (MN) associated with the first message, and wherein the second message comprises a second MN associated with the second message and does not comprise the first MN; after receiving the second message, not respond, by the first PAE, to the second PAE until a third message with the first MN is received from the second PAE, wherein the third message comprises a third MN associated with the third message; and in response to the first MN being received in the third message, send, by the first PAE, a fourth message with the third MN to the second PAE.
 2. The system of claim 1, wherein a race condition is identified in response to the second message from the second PAE not comprising the first MN associated with the first message after the first message has been sent to the second PAE.
 3. The system of claim 1, wherein the key agreement process is a media access control (MAC) security (MACsec) Key Agreement (MKA) process.
 4. The system of claim 1, wherein the first message comprises a media access control (MAC) security (MACsec) key agreement protocol data unit (MKPDU).
 5. The system of claim 1, wherein the third message comprises a potential peer type-length-value (TLV) field, and the potential peer TLV field comprises the first MN associated with the first message.
 6. A key agreement method, implemented by a first port access entity (PAE), the method comprising: initiating a key agreement process by sending a first message to a second PAE, wherein the first message comprises a first message number (MN) associated with the first message; receiving, from the second PAE, a second message comprising a second MN associated with the second message and not comprising the first MN; after receiving the second message, not responding to the second PAE until a third message with the first MN is received from the second PAE, the third message comprising a third MN associated with the third message; receiving the third message; and in response to the first MN being received in the third message, sending a fourth message with the third MN to the second PAE.
 7. The method of claim 6, wherein the first PAE initiates the key agreement process simultaneously with the second PAE.
 8. The method of claim 6, wherein a race condition is identified in response to the second message from the second PAE not comprising the first MN associated with the first message after the first message has been sent to the second PAE.
 9. The method of claim 6, wherein the key agreement process is a media access control (MAC) security (MACsec) Key Agreement (MKA) process.
 10. The method of claim 6, wherein the first message comprises MAC security (MACsec) key agreement protocol data unit (MKPDU).
 11. The method of claim 6, wherein the third message comprises a potential peer type-length-value (TLV) field, and the potential peer TLV field comprises the first MN associated with the first message.
 12. A key agreement device, comprising: a non-transitory memory storing instructions; and a processor coupled to the non-transitory memory, the instructions executed by the processor, cause the device to: initiate a key agreement process by sending a first message to a second PAE, wherein the first message comprises a first message number (MN) associated with the first message; receive, from the second PAE, a second message comprising a second MN associated with the second message and not comprising the first MN; after receiving the second message, not respond the second PAE until a third message with the first MN is received from the second PAE, wherein the third message comprises a third MN associated with the third message; receive the third message; and in response to the first MN being received in the third message, send a fourth message with the third MN to the second PAE.
 13. The device of claim 12, wherein the key agreement device initiates the key agreement process simultaneously with the second PAE.
 14. The device of claim 12, wherein a race condition is identified in response to the second message from the second PAE not comprising the first MN associated with the first message after the first message has been sent to the second PAE.
 15. The device of claim 14, wherein the race condition is avoided when the key agreement device is reflected in the third message in a potential peer type-length-value (TLV) field or live peer TLV field.
 16. The device of claim 12, wherein the key agreement process is a Mac security (MACsec) Key Agreement (MKA) process.
 17. The device of claim 12, wherein the first message comprises MAC security (MACsec) key agreement protocol data unit (MKPDU).
 18. The device of claim 12, wherein the third message comprises a potential peer type-length-value (TLV) field, and the potential peer TLV field comprises the first MN associated with the first message.
 19. The device of claim 12, wherein the key agreement device is a supplicant, and the second PAE is an authenticator.
 20. The device of claim 12, wherein the first message comprises a basic parameter type-length-value (TLV) filed, and the basic parameter TLV field comprises the first MN. 